The present invention, in some embodiments thereof, relates to a system and method for mobile network access point name (APN) virtualization and, more particularly, but not exclusively, to such virtualization in relation to mobile devices, including machine to machine devices of the Internet of Things (IoT).
The IoT (Internet of Things)/M2M (Machine to Machine) markets impose new challenges for mobile operators. Although not all IoT devices are actually mobile, they are considered herein as a subset of mobile devices since they communicate via the cellular, Internet, Wifi and other wireless networks. Some of the challenges relate to APN (Access Point Name) provisioning and management. Each cellular or mobile device has its own built in APN—access point name, which is generally the name of a server on the network through which Internet data is sent to and from the connecting IoT device, and, in the cellular network, the APN is used for finding the path for connecting a data session. When a device initiates a data session, it connects to the SGSN in a 2G/3G network, or the Serving Gateway of an LTE/4G network, or similar equipment in other cellular networks. The SGSN initiates a request for a new data session towards the core network GGSN (or the P-GW or PDN gateway in LTE networks), using GTP (GPRS Tunneling Protocol) or MIP/PMIP or other protocols corresponding to the type of networks. In order to find the IP address of the destination (the GGSN/P-GW), there is a need to use the APN that was sent by the device. The SGSN resolves the APN via DNS, translating it to an IP address of the GGSN/P-GW.
The APN is configured within the device itself, and there may be different APNs for different purposes, such as Internet, MMS (Multi-Media System), IMS/VoLTE (Voice over LTE) and of course M2M. Since at the time of manufacturing it is not always known what serving network the device may end up using, APN configuration is a serious burden. A service provider that needs to split devices between various networks needs to take care of the APN and configure the appropriate APN for each device for the actual use of the device.
A similar problem arises from the need for private APNs for certain M2M verticals (businesses, such as connected cars or e-health service providers). Such service providers may be interested in a dedicated APN, as a way of easing the billing process and the routing of all the data via a private VPN tunnel to the enterprise servers. There is thus a need to pre-configure the devices for specific verticals, with private APNs.
Another problem is the need to configure the network components with all the various private APNs. The components that need the APNs configured therein are mainly the GGSN/P-GW, and also the DNS servers.
The IoT device typically connects via the nearest base station to an SGSN (3G) Serving gateway (4G), which could be in the device's home network or in a roaming network, depending where the device happens to be located. The network then receives the APN as a string, and the string is sent to the DNS server to do APN resolution. The resolution process is the standard DNS Internet address resolution process but working on the cellular network. The APN is resolved and the connection is passed on to the GGSN (P-GW) which is at the home network. From there the connection is passed to the Internet to allow the device to access the Internet and the server that the device is programmed to communicate with.
M2M stands for machine to machine—and the devices include the smart meters, distributed sensors etc. that make up the Internet of things—if connected to the Internet.
M2M generally has specific GGSN servers that are different from those used by other devices and protocols. The GGSN may then direct the connection onwards, if necessary via secure VPN. Specific APNs may be assigned for providers of the smart devices or for end users of the devices, thus the US Police Service has its own designated APN for surveillance cameras.
As explained above, the APN is set up on the device itself and is not part of the SIM card. This raises a problem if it is necessary to change the APN, for example if the device is set up on a network other than that initially intended, or if the device is to be run by a provider other than that initially intended. Thus the operator may even go so far as to replace the SIM card but will still fail to change the APN. In fact the M2M standards for mobile network allows for a SIM download, in which it is possible to remotely reconfigure the SIM card when moving to different provider. However the SIM download does not change the APN. Rather the device itself has to be reconfigured. But often there is no-one to reconfigure the device. Remote sensors may be serviced only very rarely, and IoT devices may be owned and used without the owner particularly being aware that the device is present. There are solutions, it is possible to accept an SMS that will reconfigure the device, but a remote electricity meter or the like has no-one to accept the SMS. Another solution is to allow the device to operate scripts that are sent remotely, but allowing such scripts to run presents a security hazard.
An example of the problem is the case of car manufacturers such as BMW who provide SIM cards in all their vehicles. However the cars need different APNs for the specific country in which the vehicle is to be used, information which is not necessarily available at the time of manufacture, and cars can travel across borders.
A system provided by CISCO systems provides a virtual APN which is placed in the device's home location register (HLR). The virtual APN leads to one or more real APN's which can then be used to connect the device to a server which is different from that defined in the device, the real servers being identified by usernames provided by the device. The solution allows the device to be used with an APN other than that defined in the device, but the solution requires making changes to the HLR, which is generally discouraged in cellular systems, where the HLR is considered as a critical resource. In addition, the device needs to be tailed for the Cisco solution, and contain a specific indication for the network to use a virtual APN for it, such as a “virtual” indication in the username field that the device outputs towards the network. These two restrictions—of provisioning the HLR and the device are a serious limitation. It is noted that HLR in this document refers to the HLR of the 2G/3G mobile network, or the HSS of a 4G LTE network.